A packet switched cellular network such as GPRS or UMTS, comprises several nodes handling traffic flow and signalling within and in and out of the network. One such node is the SGSN node similar to the functionality of MSC/VLR of GSM. An SGSN is responsible for detecting MSs in its geographical area, registering them and keeping track of their movements within the routing area.
Until now, a radio network node is connected towards one and only one SGSN, as shown in FIG. 1. A radio network node is either an RNC (Radio Network Controller) or a BSC (Base Station Controller).
3GPP (3rd Generation Partnership Project), which is a standardisation body for 3rd generation mobile systems, is for the time being developing a concept where a radio network node is allowed to be connected towards several SGSNs, as shown in FIG. 2. The idea is to place several SGSNs in a pool, and that all of them cover the same geographical area, which then can be bigger than the area previously covered by one SGSN. As long as an MS is located within the pool area, the MS will be attached to the same SGSN. This has several advantages, e.g. better load sharing between SGSNs, reduced signalling in the core network, improved service performance, better scalability and easier upgrade of the nodes. Also, it opens up for several operators to share the radio network, or parts of it, while still having separate SGSNs. This is especially useful for operators having a 2G (2nd Generation) network, but who did not receive licenses for a 3G (3rd Generation) network, or vice versa. The sharing of radio network is also useful for operators who want to cut costs.
The dotted lines in FIG. 2 shows what is new with the pool concept, i.e. that an RNC or a BSC can be connected to two or more SGSNs.
When an MS is getting attached to an SGSN, the SGSN will allocate a P-TMSI (Packet-Temporary Mobile Subscriber Identity) value to the MS. In a pool concept, each of the SGSNs within the pool will have their own unique range of P-TMSI values. If the value range of each of the SGSNs is given to (known by) the surrounding nodes (BSCs, RNCs or other SGSNs), then these surrounding nodes will know to which of the SGSNs the MS is (or was) attached.
In some cases, however, the surrounding nodes will not know the P-TMSI ranges of each of the SGSNs in a pool. One example of this is when an MS roams into an area covered by an SGSN that is not aware of the pool. In this case, the new SGSN cannot uniquely identify the old SGSN to which the MS was attached. Another example is when the configuration effort is minimised so that the nodes outside an SGSN pool do not know about the internal structure of the SGSN pool. The solution to this problem is that one of the SGSNs in a pool, referred to as the default SGSN, will be appointed as a representative for the routing area covered by the pool. A new SGSN outside the mentioned routing area will look at the old Routing Area id of the MS in the received request (routing area update or attach), as usual, to determine which SGSN to contact. The default SGSN will be associated with that routing area id, and the new SGSN will therefore send a request to the default SGSN without being aware of the pool. The default SGSN will know the P-TMSI ranges of each of the SGSNs within the pool. Thus, the default SGSN can look at the received P-TMSI parameter, or the TLLI (Temporary Logical Link Identity) parameter that is based on the P-TMSI parameter if this is received instead, and forward the message to the correct SGSN. This aspect is already discussed within 3GPP (3rd Generation Partnership Project), and it is shown in FIG. 3 for the Attach procedure and in FIG. 4 for the Routing Area Update procedure. FIG. 3 and FIG. 4 show how the beginning of these two procedures must be done when using the existing procedures defined in 3GPP TS (Technical Specification) 29.060. Said TS defines the messages that are sent between two SGSNs, and the messages that are sent between an SGSN and a GGSN (Gateway GPRS Support Node, where GPRS stands for General Packet Radio Service).
Referring to FIG. 3, in step 1, the MS that previously was located in an SGSN pool area covered by the Default SGSN and the Old SGSN, roams into an area covered by the New SGSN, and sends an Attach Request message to the New SGSN. The New SGSN looks at the received ‘old Routing Area’ to find which SGSN to contact, and in this case it is the Default SGSN.
In step 2, the New SGSN sends an Identification Request message to the Default SGSN. The Default SGSN looks at the old P-TMSI to determine which SGSN within the pool handled the MS before it was roaming. The P-TMSI in this example belongs to the Old SGSN.
In step 3, the Default SGSN relays the Identification Request message to the Old SGSN. The Default SGSN must also keep information on from which SGSN it received the Identification Request message (i.e. the New SGSN) to be able to send the response to the correct SGSN.
In step 4, the Old SGSN returns an Identification Response message to the Default SGSN.
In step 5, the Default SGSN relays the Identification Response message to the New SGSN, and this is based on the information stored in step 3.
Now referring to FIG. 4, in step 1, the MS that previously was located in an SGSN pool area covered by the Default SGSN and the Old SGSN, roams into an area covered by the New SGSN, and sends a Routing Area Update Request message to the New SGSN. The New SGSN looks at the received ‘old Routing Area’ to find which SGSN to contact, and in this example it is the Default SGSN.
In step 2, the New SGSN sends an SGSN Context Request message to the Default SGSN. The Default SGSN looks at the old P-TMSI, or the TLLI (Temporary Logical Link Identity) parameter, which is based on the P-TMSI parameter if this is received instead, to determine which SGSN within the pool handled the MS before it was roaming. The P-TMSI, or the TLLI, in this example belongs to the Old SGSN.
In step 3, the Default SGSN relays the SGSN Context Request message to the Old SGSN. Since the Default SGSN must monitor the response for this message in the way the GTP (GPRS Tunnelling Protocol) protocol is defined today, the Default SGSN must change the ‘IP address’ and the ‘TEID’ (Tunnel Endpoint IDentifier) for where it wants to receive the response message. The Default SGSN must also keep information on from which SGSN it received the SGSN Context Request message (i.e. the New SGSN) to be able to send the response to the correct SGSN.
In step 4, the Old SGSN returns an SGSN Context Response message to the Default SGSN.
In step 5, the Default SGSN relays the SGSN Context Response message to the New SGSN, and this is based on the information stored in step 3.
The problem with the sequences in FIG. 3 and FIG. 4 is that the Identification Response message and the SGSN Context Response message must be sent through the Default SGSN, as shown in step 4. This means that the Default SGSN must keep some state information for this MS as well as some information on which SGSN it received the Identification Request message or SGSN Context Request message from, as described in step 3 for FIG. 3 and FIG. 4. This means that unnecessary resources are occupied and unnecessary processor load is generated in the Default SGSN. Also, this will slightly increase the time needed to perform a handover.
The concept of placing several SGSNs in a pool is not previously known in GSM (Global System for Mobile Communication). The above-described handover problems are new problems that appeared in the current standardisation of the pool concept within 3GPP, and therefore there are no known solutions to the problem.